fix: pass withSupabase error responses through middleware seam - #139
Draft
mandarini wants to merge 5 commits into
Draft
fix: pass withSupabase error responses through middleware seam#139mandarini wants to merge 5 commits into
mandarini wants to merge 5 commits into
Conversation
commit: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Middleware entries in
withSupabase'smiddlewarearray never observed the responseswithSupabasebuilds itself. This PR routes those responses through the array's response phase, with guards.Scope
WWW-Authenticate(and any decoration) on auth-generated401sOPTIONS/preflight handling from inside the arrayThe wrap form —
withOAuthProtectedResource(cfg, withSupabase(cfg, handler))orpipeline([withOAuthProtectedResource(cfg)], withSupabase(cfg, handler))— remains the supported placement for the full OAuth flow. A placement support table is added todocs/api-reference.md.Problem
Auth failures and client-construction failures returned directly, so an entry like
withOAuthProtectedResourcecould not attachWWW-Authenticateto a 401. MCP clients got a bare 401 with no pointer to the authorization server, and nothing failed loudly.Fix
The middleware chain folds once at wrap time around a dual-purpose terminal: normally it calls the user handler; when the context carries a
withSupabase-built error response under a private symbol key, it returns that response so entries run their response phase against it. Folding once means entry state (rate-limit counters, caches) is shared between the success and error paths, so a rate limiter genuinely throttles repeated bad-auth traffic.Guards bound the semantics:
console.errorand the plain error response is returned.On auth failure the context carries
userClaims: nullandjwtClaims: null, with no auth mode or clients; on client-construction failure the verified claims and auth mode are present and only the clients are absent. The OPTIONS/CORS short-circuit is unchanged, and nothing changes whenmiddlewareis absent or empty.withOAuthProtectedResourcewarns once per process when it detects (via a private context marker, not key names) that it sits inside awithSupabasearray.Tests
Fourteen new unit tests cover the routing on both error paths, the same-status and crash guards, entry-state persistence across error-path requests, header and body restoration, the context shape on each path, the in-array 401 enrichment, discovery staying wrap-form, and the placement warning (including no false positive from an unrelated
userClaimskey).Validation
Tested end-to-end against a real MCP Edge Function in supabase-community/edge-function-mcp-sandbox#11: 401 enrichment works, authenticated MCP calls unaffected, discovery/preflight behave as documented, warning fires.
🤖 Generated with Claude Code